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AMENDMENTS TO THE SPECIFICATION : 

Please replace the paragraph beginning on page 1, line 19 and 
ends on page 2, line 4 with the following rewritten paragraph: 
— Public information in a network of the above kind is 
distributed within the group of users by IP-multicast in the form 
of streamed media. However, there may be a need for distribution 
of information of particular interest to only a sub-part of 
participating users, and to distribute private messages 
exclusively within that sub-part of the participating group. 
According to prior art technology, in such a case a special 
communication channel is established between the sub-group 
members in parallel with the public multicast communication 
channel. However, network constraints, such as firewalls or other 
access limiting security arrangements may impede or even preclude 
transmission of non-multicast communication from reaching the 
intended recipient. This is a drawback associated with prior art, 
which limits the deployment of applications for group 
communication. Today, the trend in society is that measures are 
taken in the direction of enhanced security, and the security 
consciousness among users and network administrators has 
increased. Therefore the need for an arrangement enabling 
coimuunication, while simultaneously respecting network 
constraints and limitations, such as firewalls and other security 
measures, has become even greater than before. 
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Please replace the paragraph beginning on page 2, line 8 and ends 
on line 22 with the following rewritten paragraph: 
— It is therefore an object of the present invention to alleviate 
the previously mentioned shortcomings of prior art associated 
with group communication services. This is accomplished by an 
apparatus and method for distribution of a streamed signal within 
a group of users in a computer network, the users accessing 
client terminals for participation in a multicast session, the 
apparatus comprising, 

connecting links adapted to connect the client 
terminals of users and related equipment, such as capturing 
means, to the multicast session, preferably via the Internet or 
other interconnecting network, 

an extension header being added to data packets of the 
streamed signal, the extension header comprising identification 
data relating to the intended recipient of a packet, 
characterised in that 

a filtering means associated with the receiving client 
is adapted to filter out data packets comprising identification 
data in the extension header identifying the recipient and 
receiving the streamed signal. -- 

Please replace the paragraph beginning on page 6, line 1 and ends 
on line 21 with the following rewritten paragraph: 
--The extension name is set to a common identifier, identifying 
this extension as a filter destination. In accordance with a 
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preferred embodiment of the invention, the filter destination 
header is identified by the bytes numbered 77 and 65. The 
"length" field is the total length of the header extension 
including the first 4 bytes. Reference is here made to the RTP 
specification IETF RFC1889 (request for comments) where the first 
4 bytes are defined, "v" which is found far left in Fig 2 defines 
two bits primarily intended for making changes possible within 
the header extension. "X" denotes an unused field in the header, 
"and" is a command that allows alternative use of the header 
extension. The reason for this possible alternative use is that a 
stream can only contain one RTP header extension per packet if it 
is to conform with the RTP specification. In this case the 
command cmd is set to 0. "dest number" is the number of 
destinations in this particular packet, which may be any number 
relating to the size of the sub-group of intended recipients . 
"real payload" is the type of data being sent in this packet. The 
real RTP header contains a payload type field and just as the 
case of other applications, and it is not intended to be possible 
to decode the data by leaving out the extension header. This 
extension header is originally set to the original value of 127. 
This number denotes, in accordance with the mentioned RTP 
specification, "unspecified" and then includes the real payload 
type. This will lead to applications that do not interpret this 
header extension to dispose of the packet. ID1, ID2, ... are the 
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unique identifiers for the intended destination, i.e. who the 
intended recipient of this packet is.-- 

Please cancel the originally- filed Abstract of the 
Disclosure, and add the accompanying new Abstract of the 
Disclosure which appears on a separate sheet in the Appendix. 
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